Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-030.txt

Text File | 1992-11-18 | 38.1 KB | 1,049 lines | [TEXT/MPS ]

C.S.M.P. Digest             Tue, 24 Mar 92       Volume 1 : Issue 30

Today's Topics:

    Mac CLOS/TCP-IP packages?
    Safe ExitToShell from Think Pascal
    Printing PostScript without Apple's crapola
    68881 code with THINK C 4.02
    Problem compiling NewClassDemo using TC5.0.2 and TCL1.1.2
    Ok, where are the 411 file on ETO6?
    Dynamically Loading Subclasses in TC5.0
    TCL, RequestMemory() & Error 28
    Compression--is it worth it?
     6.07 Bug
    patching StripAddress
    Chinese OS?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Andrew Myers)
Subject: Mac CLOS/TCP-IP packages?
Organization: MIT Laboratory for Computer Science
Date: Fri, 14 Feb 1992 21:50:20 GMT


I will shortly be writing an application which needs to connect CLOS
running on a Mac to a UNIX box, using TCP-IP. Does anyone have a
package that can expedite this process, such as TCP-IP bindings for
CLOS? Thanks,

Andrew



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Mac CLOS/TCP-IP packages?
Date: 16 Feb 92 08:48:16 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Andrew Myers) writes:
> I will shortly be writing an application which needs to connect CLOS
> running on a Mac to a UNIX box, using TCP-IP. Does anyone have a
> package that can expedite this process, such as TCP-IP bindings for
> CLOS? Thanks,

I saw that the MCL 2.0 final package has a TCP streams module. Don't remember
if this was present on 2.0b1 or the b4 patches (I think so), I kind of deleted my
early versions when I got the pre-release of the final MCL.

Kent Sandvik/DTS



- -------------------------

From: [e-mail] (Paul Frederick Snively)
Subject:  Mac CLOS/TCP-IP packages?
Date: 15 Feb 92 08:11:03 GMT
Organization: The Portal System (TM)

[The poster asked about using CLOS in MCL to talk to UNIX boxes over TCP/IP.]

I'm not quite sure, from your post, what you're looking for.  If you want to
`roll your own' stuff at the TCP/IP level, then I suggest that you FTP the
corrected MacTCP interface file for MCL 2.x from brazil.cambridge.apple.com
(look in the MCL2 directory).

A better approach might be to FTP to ftp.ncsa.uiuc.edu and look in
misc/unsupported for a mostly-Berkeley-compatible socket library using MacTCP.
You could link the socket library into your code using the Foreign Function
Interface, and then write CLOS classes around it.  You may wish to scare up
the "Socket Streams" code that's been discussed in comp.lang.c++ and work from
that.  The advantage here, of course, would be that a) you could talk to
anything that groks Berkeley sockets (i.e. pretty much the entire UNIX world)
and b) you could use pretty normal-appearing stream-oriented I/O to do it.

Paul Snively
Dissolute Wandering Hacker
[e-mail]    <-- please mail me here, if you wish to mail me at all.



---------------------------

From: laplace.biology.yale.edu (Warren DeLano)
Subject: Safe ExitToShell from Think Pascal
Date: 16 Feb 92 08:27:09 GMT
Organization: Yale University

Is there a way to use the ExitToShell command from TMON
to exit a program (running under Think Pascal) that
doesn't cause a crash?

ExitToShell works fine when killing programs in Think C, but
it has never worked for Think Pascal.

Thanks
Warren

[e-mail]



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  Safe ExitToShell from Think Pascal
Date: 20 Feb 92 21:38:53 GMT
Organization: Symantec Language Products Group


In article <[e-mail]> laplace.biology.yale.edu (Warr:
>Is there a way to use the ExitToShell command from TMON
>to exit a program (running under Think Pascal) that
>doesn't cause a crash?

Bring up the Registers window, and set the PC to !_ExitToShell, and then
exit TMON.

R.

--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



---------------------------

From: [e-mail] (Ben Haller)
Subject: Printing PostScript without Apple's crapola
Date: 20 Feb 92 15:42:40 GMT
Organization: Stick Software


  Well, those of you who know me as the "Rebel Without A Cause" who hates
everything Apple does (not really, but almost :->) will not be surprised by
this latest rant.  But - surprise - it has nothing to do with
direct-to-screen drawing?  No, I've moved on to direct-to-printer drawing
now :->
  I am trying to print PostScript.  I am currently using the PicComment
method of enclosing PS commands within a picture, and then printing the
picture.  However, I am not happy with this.  The reason is that Apple's
DSC (Document Structuring Conventions, see the Red book) comments are
getting in my way.  For example, they give a bounding box of "? ? ? ?" when
in fact I know quite well what my bounding box is, and would like it to be
in the header.  They don't list the fonts that I use in the DocumentFonts
comment, they say the wrong number of pages, the wrong creator, title, they
spew out their header and then say "%%EndProlog" when in fact not only do
I not want and not use their header, but I have a prolog of my own thank
you very much.
  So I could just go directly to the ".PAP" (I think that's the name)
driver and to hell with the OS.  However, I'd like to get the standard
printer dialogs (I will emit the code to do portrait vs. landscape and such
myself unless there is a good reason to let Apple do it around me), I'd
like to get spooled by PrintMonitor, etc.
  So is there a middle ground?  Is there a way to print PostScript by just
handing the system my code and saying "here, this is a complete file, don't
mess with it" while still doing all the nice things the user expects?
  On a slightly different topic, is there a way to tell whether the printer
I'm going to is a PostScript printer or not?  I *can* generate QuickDraw
for non-PostScript printers.  But I want to generate the PostScript myself
when possible.
  Basically I'm trying to be as compatable as possible while still
completely taking over the system.  Business as usual...

-Ben Haller ([e-mail])



- -------------------------

From: [e-mail] (Jeff E Mandel)
Subject:  Printing PostScript without Apple's crapola
Date: 21 Feb 92 20:04:26 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> [e-mail] (Ben
Haller) writes:
>  So I could just go directly to the ".PAP" (I think that's the name)
>driver and to hell with the OS.  However, I'd like to get the standard
>printer dialogs (I will emit the code to do portrait vs. landscape and such
>myself unless there is a good reason to let Apple do it around me), I'd
>like to get spooled by PrintMonitor, etc.

There is a C++ library which I wrote to go to PAP. It is available on
rs1.tcs.tulane.edu (it is the only Mac file there, I believe). I have used it
to implement an XCMD to send the passed container to the printer, and
optionally return information from the printer.

As for using the Apple dialogs, there is nothing to stop you from doing this
and just extracting the information you want from the record, then deleting the
printing record and accessing PAP. As for knowing whether you have a Postscript
device, a reasonble (but not perfect) solution is to see what kind of device
the printer is (from an NBP perspective); a LaserWriter is generally
Postscript.

The main problem with PAP is it presumes the printer is on the network; a
serial or SCSI attached printer won't show up. Other than that, if you are
willing to manage all of the Postscript generation, PAP is significantly faster
than PICT comments. My silly MS Works Mail Merge Enhancer (on the MacHacks '91
CD-ROM), rewritten to use PAP, drives a DataProducts LZR 1260 at its
paper-handling speed from a Mac LC now.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]



- -------------------------

From: [e-mail] (Marshall Clow)
Subject:  Printing PostScript without Apple's crapola
Organization: Hewlett Packard Color Imaging Division
Date: Fri, 21 Feb 1992 20:33:35 GMT

In article <[e-mail]>, Jeff E Mandel <[e-mail]> writes:
> As for knowing whether you have a Postscript device, a reasonble
> (but not perfect) solution is to see what kind of device
> the printer is (from an NBP perspective); a LaserWriter is generally
> Postscript.>

The way that I use to determine if a printer driver prints to a PostScript
printer is to check the PACK(-4096) resource in the driver. The long word
at offset $C in the resource contains lots of flags. Among the interesting
ones are:
          Bit 31:    Set if AppleTalk device.
          Bit 30: Set if device uses PAP
          Bit 29: Set if device uses PostScript

Note that this information is specific to the printer driver, not to the
printer, but they usually come as a pair.

Marshall Clow
Mac Driver Development
San Diego Printer Division
Hewlett Packard
[e-mail]




- -------------------------

From: [e-mail] (Christopher Tate)
Subject:  Printing PostScript without Apple's crapola
Date: 22 Feb 92 02:39:29 GMT
Organization: Penn State University

In article <[e-mail]>, Jeff E Mandel
<[e-mail]> says:
>
>There is a C++ library which I wrote to go to PAP. It is available on
>rs1.tcs.tulane.edu (it is the only Mac file there, I believe). I have used it
>to implement an XCMD to send the passed container to the printer, and
>optionally return information from the printer.

I fetched down this file (which BTW is in the /pub/mac directory, with
the file name dopap-xcmd.hqx), and discovered that it is incomplete.
Specifically, attempting to un-binhex it resulted in an "unexpected
end-of-file" error.  I checked, and the last partial line of the file
does not end with a ':' character, as it should.  Appending a ':' also
failed to work.

I'm also interested in getting hold of this code; could the binhex file
on the FTP site be replaced with a clean copy?

- -----
Christopher Tate                 |  Cryptogram #8:
[e-mail]             |
[e-mail]              |  UNOSKVL OR EWKV DGQ LAYLUV.
- -------------------------------|  ELKVWLM OR EWKV DGQ HLV.
Send me the answer; I love mail! |



- -------------------------

From: [e-mail] (Jeff E Mandel)
Subject:  Printing PostScript without Apple's crapola
Date: 22 Feb 92 04:52:46 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> Christopher Tate
<[e-mail]> writes:
>
>I fetched down this file (which BTW is in the /pub/mac directory, with
>the file name dopap-xcmd.hqx), and discovered that it is incomplete.
>Specifically, attempting to un-binhex it resulted in an "unexpected
>end-of-file" error.  I checked, and the last partial line of the file
>does not end with a ':' character, as it should.  Appending a ':' also
>failed to work.
>
>I'm also interested in getting hold of this code; could the binhex file
>on the FTP site be replaced with a clean copy?
>

Sorry, not my archive. I'll see what I can do about it next week.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]



---------------------------

From: [e-mail]
Subject: 68881 code with THINK C 4.02
Date: 20 Feb 92 15:31:26 GMT
Organization: New Jersey Institute of Technology


        I'm trying to compile some code I've written to do a fairly basic math
problem (Gaussian elimination on the Hilbert matrix) on an SE/30 with System
6.05 and Think C 4.02. (I wish I could afford the upgrade right now, but it's
probably not relevant for my purposes.) The code is all ANSI standard C and
compiles and runs fine on both a SPARC II and a SUN 3 using gcc 1.40. I'm
trying to move it to the Mac because of its higher precision arithmetic. If I
uncheck the 68881 code generation option for Think C, then the code compiles
and runs properly.  I'd like to be able too use the 96 bit precision of the
68881, but when I check the 68881 code generation option, everything still
compiles and runs, but the answers are garbage. I realize the Hilbert matrix is
ill-conditioned but, even for small Hilbert matrixes (dimension = 2 for
example) that aren't ill-conditioned the answers are complete garbage. And if I
don't compile for the 68881 then the answers with the exact same code, are
fine.
        I'm including the ANSI library in my project, and also #including the
headers stdio.h, stdlib.h, and math.h. Is there anything I'm missing? An
additional library to add to the project or file to #include? This really has me
baffled.
        Because of the number of different systems this code compiles and runs
successfully on, I'm reasonably sure this is a Think C question rather than a
generic C question, which is why I'm posting it here. Please send answers or
suggestions by E-mail if possible since I generally don't read this newsgroup.

Elliotte Rusty Harold                      Department of Applied Mathematics
[e-mail]                  New Jersey Institute of Technology
[e-mail]                       Newark, NJ 07103



- -------------------------

From: [e-mail] (Bevin L Harris)
Subject:  68881 code with THINK C 4.02
Date: 20 Feb 92 20:07:12 GMT
Organization: Iowa State University

Just a thought- have you added ansi to prject rather than ansi881. If not the
results from the program will be garbage.



---------------------------

From: [e-mail] (Cindy Hao)
Subject: Problem compiling NewClassDemo using TC5.0.2 and TCL1.1.2
Date: 20 Feb 92 16:54:20 GMT
Organization: Massachvsetts Institvte of Technology

I have just updated my ThinkC from 5.0.1 to 5.0.2, but now I cannot
compile NewClassDemo.

I got the following error message: no such member 'cHaveIconDispatch'
at the line "Boolean CIconPane::cHaveIconDispatch = FALSE;" in
the program CIconPane.c.

I checked that in CIconPane.h cHaveIconDispatch was indeed a member as
defined on the line:
"static Boolean cHaveIconDispatch;   // TCL 1.1.2  "

Can anybody tell me what's wrong?  (Some other programs of mine do not
compile any more for the same reason.)

Thanks.

-Cindy
--

- ----------------------------------------------------------------
Cindy Hao                        NW14-2524
email:[e-mail]             150 Albany Street



- -------------------------

From: [e-mail] (Cindy Hao)
Subject:  Problem compiling (Please Ignore!!)
Organization: Massachvsetts Institvte of Technology
Date: Thu, 20 Feb 1992 17:19:28 GMT

Please ignore the about posting.  I have solved the problem.
I had to re-precompile my TCLHeaders.

Sorry about it.

--
- ----------------------------------------------------------------
Cindy Hao                        NW14-2524
email:[e-mail]             150 Albany Street
tel:  [phone]            Cambridge, MA 02139



---------------------------

From: [e-mail] (Blair M. Burtan)
Subject: Ok, where are the 411 file on ETO6?
Date: 20 Feb 92 17:10:58 GMT
Organization: Boston U. College of Engineering

Am I dreaming?  I can't seem to find any of the 411 files on ETO #6?
Could someone tell me where they are?
--
+---------------------------------------+
+ "If it isn't Baroque, don't fix it."  +
+               - Beauty and The Beast  +
+                        +
+ Blair M. Burtan: [e-mail]    +
+                  [e-mail]   +
+---------------------------------------+





- -------------------------

From: [e-mail] (Jerome Jahnke)
Subject:  Ok, where are the 411 file on ETO6?
Date: 20 Feb 92 18:23:29 GMT
Organization: Biology Learning Center

In article <[e-mail]>, [e-mail] (Blair M. Burtan) writes:
>
> Am I dreaming?  I can't seem to find any of the 411 files on ETO #6?
> Could someone tell me where they are?

I found them on ETO #5 :-).

Serioulsy I think the Q A guys were asleep at the wheel on #6. There were a
number of things missing from what I can tell. 411 and the Installer were the
biggest to my mind. But what do you expect so soon after the MacWorld Blitz?

It also looks to me that we are on the cusp of getting two disc's. And I think
the missing items bring this point even closer to home.

> --
> +---------------------------------------+
> + "If it isn't Baroque, don't fix it."  +
> +               - Beauty and The Beast  +
> +                        +
> + Blair M. Burtan: [e-mail]    +
> +                  [e-mail]   +
> +---------------------------------------+
>
>

Jer,
- --
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' OR [phone]



- -------------------------

From: [e-mail]
Subject:  Ok, where are the 411 file on ETO6?
Date: 21 Feb 92 07:29:37 GMT
Organization: Actrix Information Exchange

::sigh::

A notice about that was posted here a week or so ago.  Not only
that, but APDA sent out a letter to ETO subscribters about the
problems -- I've got the letter, but not the damn ETO itself.

In short: they accidently left 411 off ETO #6, but it wouldn't
have changed from what was on ETO#5.  (And apparently won't
change in ETO #7 either, which is the subject of another
discussion altogether about *when* it will be properly updated
for IM VI).

--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Jim Spencer)
Subject: Ok, where are the 411 file on ETO6?
Date: 22 Feb 92 15:29:06 GMT


 BM> Am I dreaming?  I can't seem to find any of the 411 files on ETO #6?
 BM> Could someone tell me where they are?

You aren't dreaming, you are having a nightmare.  They "forgot" to put them
on the disk so you have to use the ones on ETO #5 (there are 411 files
present on #6 for MacApp 3.0).  You should get a letter from APDA telling
that they also have serious bugs in the MPW Shell in the Final Release
folder (vers. 3.2.1) and in the latest C compiler.

Considering that this release is over 2 months late, is badly bug ridden,
and that ETO #7 is still coming out next month making ETO #6's value pretty
limited, it strikes me that maybe Apple should be extending everyone's
subscription.  Sending two letters, one to say they are going to be late
and a second to say they messed up the disk but we can pay even more and
download fixes from AppleLink (at our nickel) or use what we already have
just isn't very fair.
 * Origin: We don't need no stinkin badges!! (1:282/22.510)



---------------------------

From: [e-mail] (Bradley Green )
Subject: Dynamically Loading Subclasses in TC5.0
Date: 20 Feb 92 19:47:13 GMT
Organization: University of Pennsylvania

System: Think C 5.0.2, System 7.0

I have an application which I am writing in which I would like to be able
to define a slew of subclasses of a specific object class, each with a
different functionality.  Then the user would choose which options he/she
desired, and only the code for those subclass methods would be loaded.  Can
this be done?  Is a code resource the way to do it, and does TC support this
option?

The eventual goal is to be able to distribute the main package and sell the
additional subclass extensions as options.

Thank you for any assistance youcan provide.  Please e-mail me instead/in
addition to posting, as the huge number of daily messages on this newsgroup
prohibit me from reading them all



- -------------------------

From: [e-mail]
Subject:  Dynamically Loading Subclasses in TC5.0
Date: 21 Feb 92 16:45:28 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Bradley Green ) writes:
> I have an application which I am writing in which I would like to be able
> to define a slew of subclasses of a specific object class, each with a
> different functionality.  Then the user would choose which options he/she
> desired, and only the code for those subclass methods would be loaded.  Can
> this be done?  Is a code resource the way to do it, and does TC support this
> option?
>
> The eventual goal is to be able to distribute the main package and sell the
> additional subclass extensions as options.

The easy way to do it would be to just put all the methods for each
subclass in their own segment (you can do this easily in MPW or in THINK
Pascal -- I haven't used THINK C) and link the whole application normally.

You would then use ResEdit (or whatever) to remove the CODE resources for
the classes you wanted to make optional and paste them into their own
extensions files.

The application jump table will still contain entries for each class (and
therefore you'll need to know what extensions are possible when you compile
the application) so you'll need to make sure the logic of the program
doesn't let you try to use the removed classes.  To dynamically load the
classes all you have to do is open the extensions resource file containing
them before using them.

Voila!  Crude, but it will work.

--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



---------------------------

From: [e-mail] (Mark)
Subject: TCL, RequestMemory() & Error 28
Date: 20 Feb 92 22:01:26 GMT
Organization: University of California, Berkeley

In trying to Append an object onto a CList, I got an error 28 - "stack has
moved onto application heap".  The culprit appears to be the RequestMemory()
function which sets up the canFail flag before a memory allocation is made.

My guess is that the RequestMemory() function is so deep in the control
chain that the stack grew too large, and boom.  The problem is, I don't have
a clue about what to do about it.  HELP!

What can I do to give more space to the stack?  Or, could this just be
symptomatic of other memory-related problems?

Thanks for any advice,

Mark Thomas



- -------------------------

From: [e-mail] (Eric W. Sink)
Subject:  TCL, RequestMemory() & Error 28
Date: 21 Feb 92 14:33:50 GMT
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] (Mark) writes:

>What can I do to give more space to the stack?  Or, could this just be
>symptomatic of other memory-related problems?

Look in the OOP programming manual, towards the back, under

SetMinimumStackSize.

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]



---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Compression--is it worth it?
Date: 21 Feb 92 05:29:52 GMT
Organization: University of Waikato, Hamilton, New Zealand

I got two upgrades to version 3.0 of Canvas yesterday--one for use at work,
and one for my personal copy at home. The first thing I noticed was that
they use Apple's Installer, which is a pain, because it quits everything
that's currently running before doing the install, and then forces me to
restart my machine afterwards.

But an even bigger pain turned out to be the time it took to decompress
all the compressed files. The installation on my IIfx at work only a took
a few minutes, but the one on my LC at home took at least a quarter of an hour!
It probably took longer, but at that point I left it and went to do some
shopping. Thankfully, it was done about three-quarters of an hour later,
when I came back.

The upgrade came on four double-density disks. After it was all installed,
and I'd personalized it, I copied all the (uncompressed) files onto floppies,
to save the trouble of a reinstall, should I need to do one in future.
I got all the files onto four high-density disks and one double-density one.

Now, I ask you, would it have been so much more trouble and expense to
distribute 8 or 9 double-density disks of uncompressed files, instead of four
disks compressed? Think of how much more quickly the installation would
have gone.

Compression is all very well for low-bandwidth transmission of data, like
over a modem, but I wonder about the point of it for distributing stuff
on disk. If it had made the difference between distributing 10 floppies
instead of 20, or an even larger number, there might just be a point
where the decompression time is less than the time it would take to
copy the stuff off the extra floppies. But this Canvas upgrade certainly
didn't reach that point.

By the way, the new Canvas is a neat program. Haven't gone through the
whole manual yet, but a lot of my wishes have already been answered--
you can create and edit 8- and 32-bit-per-pixel paint objects, and you
can change anchor points of cubic Bezier curves from curve points to corner
points, and back again--like you can in FreeHand! Still some irritating
restrictions on bitmap resolutions, though.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
"A lot of vendors are offering what I call the three 'lesses'--diskless,
colorless and useless."
          -- Charles Foundyller, quoted in Computerworld of Jan 20



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Compression--is it worth it?
Date: 21 Feb 92 15:50:38 GMT
Organization: Kalamazoo College

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>I got two upgrades to version 3.0 of Canvas yesterday...
>... an even bigger pain turned out to be the time it took to decompress
>all the compressed files. The installation on my IIfx at work only a took
>a few minutes, but the one on my LC at home took at least a quarter of an hour!
>Now, I ask you, would it have been so much more trouble and expense to
>distribute 8 or 9 double-density disks of uncompressed files, instead of four
>disks compressed? Think of how much more quickly the installation would
>have gone. ...
>If it had made the difference between distributing 10 floppies
>instead of 20, or an even larger number, there might just be a point
>where the decompression time is less than the time it would take to
>copy the stuff off the extra floppies.

Reducing the number of disks shipped is very important.  Software
companies sometimes have quite a low overhead, and each extra disk bites
another chunk out of it.  It can make a very big difference, believe me.

Decompression time isn't so bad.  Grin and bear it.  If you need
something to do, spend the 45 minutes thanking your lucky stars you
didn't buy an IBM--command-line dearchiving is no treat.

My opinions, I'm not speaking for anyone else.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



---------------------------

Subject:  6.07 Bug
From: [e-mail]
Date: 20 Feb 92 08:42:14 CST
Organization: Brandon University, Brandon, Manitoba, Canada

In article <[e-mail]>,I wrote:
> Does anybody know anything about a bug in Think C 5.02 (and 4) related to the
> header used for deskaccessories?
> I am writing a multisegment deskaccessory. I usually cannot make it cause a
> system error except in a very specific kind of circumstances:
> On an LC (and possibly other machines, but not on a Plus) running system 6.07
> without MF (and possibly other system configurations): After the DA has been
> freshly installed, i.e. the computer has not been rebooted since the DA was
> moved into the System by DA mover 3.8 or 4.1 and the DA was not already in
> the system, selecting the DA from the Apple menu causes an immediate
> "illegal instruction" system error: the programme tries to execute an
> instruction not in any heap zone but happens to be 2 bytes off the proper
> allignment.
> This error occurs before any of my instructions are reached, i.e. a
> Debugstr call at the beginning of main is never executed.
I blamed the wrong code: it's not Think C and it's not my code either but
it seems to be a bug in the operating system: It happens also with the
Apple supplied Calculator DA (I didn't try it with any other DA) and the
"illegal instruction" system error occurs exactly if the DA is installed
with an ID that was not in used at last startup. (The LC/6.07 used only
Apple supplied INITs, ATM 2.03 and FontPorter.) I am unable to figure out
whether maybe some of these cause the problem since the LC isn't my
machine and everrything wotrks fine on the MacPlus I have.
- -----------------------------------------------------------------------------
Andreas Guelzow  Dept. of Mathematics & Comp. Sc. Brandon University MB Canada
[e-mail]



---------------------------

From: [e-mail] (Pete Gontier)
Subject: patching StripAddress
Date: 21 Feb 92 02:24:18 GMT

Last night I had a light bulb go on in my head. Maybe a dim bulb,
but a bulb nevertheless.

I figure if System 7.0.1 (OmegaSANE) can hack applications which
call the SANE trap to JSR instead to the floating point code,
why not do the same for _StripAddress?

I figure there ought to be a way to nuke calls to _StripAddress
if the machine's in 32-bit mode. Yes, of course it's much more
complex than that. Probably whether the *heap* is a 32-bit heap
is more important than whether the machine is in 32-bit mode.

But I haven't gotten that far yet. I attempted to patch
_StripAddress in the way I always do, with "known-good" routines
for patching. But when I call NSetTrapAddress against
_StripAddress, the machine hangs.

I figured this might have something to do with NSetTrapAddress
calling _StripAddress when the _StripAddress trap table entry is in an
inconsistent state. But I don't feel like putting the time in
to figure out the format of those tables to see what's going on.

Hints? Anybody feel like writing this? I was going to give it
away anyway.
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  patching StripAddress
Date: 21 Feb 92 14:51:31 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Pete Gontier) writes:
>
>I figure there ought to be a way to nuke calls to _StripAddress
>if the machine's in 32-bit mode. Yes, of course it's much more
>complex than that. Probably whether the *heap* is a 32-bit heap
>is more important than whether the machine is in 32-bit mode.
>
>But I haven't gotten that far yet. I attempted to patch
>_StripAddress in the way I always do, with "known-good" routines
>for patching. But when I call NSetTrapAddress against
>_StripAddress, the machine hangs.

    Why bother patching _StripAddress? Why bother *calling* _StripAddress
more than once in your entire application? Here's how I do it...

unsigned long addrMask;

addrMask = StripAddress(-1L); // which computes the right mask for 24 & 32 bit

to mask, just use (addr & addrMask). No messy trap calling, and only one call
to _StripAddress at the beginning of your program sets up this global for
the life of the application.

R.



--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  patching StripAddress
Date: 22 Feb 92 01:05:43 GMT


 RS> From: [e-mail] (Rich Siegel)

 RS>     Why bother patching _StripAddress? Why bother *calling* _StripAddress
 RS> more than once in your entire application? Here's how I do it...

The idea was to write an INIT which retroactively NOPs out calls to
StripAddress which are already in binary applications.
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



---------------------------

From: [e-mail] (Demian)
Subject: Chinese OS?
Date: 23 Feb 92 02:39:26 GMT
Organization: University of California, Berkeley


Hi, I'd like to know if there's a PD software that allows the Macintosh
System to be displayed in Chinese characters?  I've seen a Japanese
Kanji version so I was wondering if a Chinese one existed?
Preferably easy to access at an ftp site?
Thanks, email appreciated.

-Demian



- -------------------------

From: [e-mail] (Shueh-Fen Lin)
Subject:  Chinese OS?
Date: 23 Feb 92 03:22:32 GMT
Organization: UB

In article <[e-mail]> [e-mail] (Demian) writes:
>
>Hi, I'd like to know if there's a PD software that allows the Macintosh
>System to be displayed in Chinese characters?  I've seen a Japanese
>Kanji version so I was wondering if a Chinese one existed?
>Preferably easy to access at an ftp site?
>Thanks, email appreciated.
>
>-Demian

This info should be helpful sto you.

Apple also has Chinese System, it is called ChineseTalk.  Currently we have
two versions: one is Traditional character version used mainly in Taiwan; the
other is Simplified character version used in mainland China.  However,
this is only true for System 6.0x.

What happened after System 7.0?

There is an extension system used under System 7.0 in Taiwan. It will
let System 7.0 users display and enter Chinese characters.  Although not
a whole system itself, Apple Taiwan calls it ChineseTalk II.

Don't know if there is also Simplified character version of ChineseTalk II
in mainland China.

ChineseTalk 6.0x could be found in ftp.apple.com I guess.   If not, the
best source is APDA's develop CD-ROM which is published per quarter.

[e-mail]




- -------------------------

From: [e-mail] (Youngwhan Lee)
Subject:  Chinese OS?
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 23 Feb 1992 04:53:20 GMT

In <[e-mail]> [e-mail] (Shueh-Fen Lin) writes:

>In article <[e-mail]> [e-mail] (Demian) writes:
>>
>>Hi, I'd like to know if there's a PD software that allows the Macintosh
>>System to be displayed in Chinese characters?  I've seen a Japanese

>Apple also has Chinese System, it is called ChineseTalk.  Currently we have
>two versions: one is Traditional character version used mainly in Taiwan; the
>other is Simplified character version used in mainland China.  However,
>this is only true for System 6.0x.

Do you mean ChineseTalk is a PD? Is it right?

youngwhan.
--
[e-mail], [e-mail]           | University of Illinois
1408 W. University Ave., Urbana, IL. 61801  | Computer Science
[phone]                   |
Yes, I believe in science, but nothing else.| Innosys? What is it?



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Chinese OS?
Date: 23 Feb 92 10:44:31 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@sunb10.cs.uiuc.edu> [e-mail] (Youngwhan Lee) writes:

   Do you mean ChineseTalk is a PD? Is it right?

No, it's licensed to use on any Apple computer. You may not disassemble,
run on non-apple computers, or such things. That's the way system
software USED to be at Apple. Rumor has it, that's changing, but as of
today, I believe it should be free-for-use from licensed distribution
centres (i.e. your Apple dealer or MUG or ftp.apple.com)

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Shueh-Fen Lin)
Subject:  Chinese OS?
Date: 23 Feb 92 13:38:35 GMT
Organization: UB

>
>Do you mean ChineseTalk is a PD? Is it right?
>

It is NOT a PD, it is a System software, just like System 6.05, System 7.0,
etc.  You use the same method to get ChineseTalk as the way you get new
Systems. :-)



- -------------------------

From: [e-mail] (P. Hawthorne)
Subject:  Chinese OS?
Date: 23 Feb 92 18:06:57 GMT
Organization: Reed College, Portland OR


 The Macintosh Office in China? Great. It has more of a chance at bringing
 about change than the young democrats who were thrown in prison after the
 demonstrations. I think internationalism is great as long as you're doing
 the exporting and the product is as good as Macintosh....

 Theus ([e-mail])
"I have sworn upon the altar of God eternal hostility to all forms of
 tyranny over the mind of Man," - Thomas Jefferson



---------------------------

End of C.S.M.P. Digest
**********************